NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/59

Internet Message Format | 1996-08-06 | 3.3 KB

From: Dick Menninger <[e-mail]>
Message-ID: <[e-mail]>
X-Original-Date: Thu, 18 Jan 1996 00:17:21 GMT
Path: in1.uu.net!bounce-back
Date: 18 Jan 96 00:50:31 GMT
Approved: [e-mail]
Newsgroups: comp.std.c++
Subject: Re: Throwing an exception from within a si
Reply-To: mennid <[e-mail]>
Organization: AT&T Global Information Solutions
X-Newsreader: DiscussIT 2.5.1.3 for MS Windows [AT&T Software Products Division]
References: <4dgj4m$[e-mail]>
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMP2ZZeEDnX0m9pzZAQFGXQF9G8gI6yvGHAvqM1DPYWmK/H6MxucmiDIl
    H3nX0KeilP958O94p6clo1yj61edaY6w
    =S8Lx

> ==========Steve Clamage, 1/16/96==========

> In article [e-mail], [e-mail] (Tom Payne) writes:

> >Implicit in a qestion of what the Standard says are the related
> >questions of what it should say and why --- why shouldn't signal
> >handlers be allowed to throw exceptions?  (The question seems both
> >interesting and appropriate.)

> Exceptions are synchronous, and unwind the stack from the point of the
> throw to the point of the handler. When an asynchronous signal arrives,
> what is the state of the stack? Answer: unknown. In particular, the
> stack might not even be in a consistent state -- arguments half pushed
> during function entry or half popped during exit.

Signal handlers are analogous to interrupt handlers at
application level.  They form separate asynchronous
processing that may communicate to the rest of the
application but are really a separate thread.  How they
communicate to the rest of the application is colored
thoroughly by their nature.  The problem in thinking
about exceptions in signal handlers seems to be that
everybody is treating them as part of the thread they interrupt.
That leads you down the path to oblivion.  They should
be seen as a separate thread of execution.  An exception
does not go back through the special save boundary.
To do that would be like an exception in one thread
continuing through another threads stack.  When you
look at a signal handler as a threadlike thing that happens
to preempt another thread, you start making sensible
decisions that allow a signal handler to do that little
more that is probably necessary.  Since exceptions
are required at rather basic levels now, precluding
them is very unrealistic.

> In C, a signal handler isn't allowed to do much of anything, precisely
> because the program state can't be known and may be inconsistent. The
> same is true in C++.

It is just like an interrupt handler in that it could
deadlock with the code it preempts.  OSes deal with
that and do quite meaty stuff in the interrupt handlers.
I certainly hope you are NOT trying to preclude the
use of exceptions in interrupt handlers.  That would
be totally absurd.

> Allowing exceptions to be thrown from a signal handler would place a
> noticeable penalty on all programs to provide locks on every function
> entry and exit, even programs that didn't throw exceptions or use
> signals.

I don't think so.  That does not follow at all.
See the earlier comments.

Good Day
Dick
[e-mail]
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]